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"An Interface Module For Mobile Telecommunication Systems" 



Introduction 

The invention is directed towards providing for access to databases on mobile 
telecommunication systems such as those which store mobile subscriber feature data. 

At present, such data can be controlled using special feature codes from a mobile handset. 
However, the feature codes are complex to use and difficult to remember, and also use of 
a mobile handset is required. 

Statements of Invention 

According to the invention, there is provided an interface module comprising means for 
allowing client systems to read and write mobile subscriber feature data in a HLR. 

In one embodiment, the module uses MAP operations over a signalling network. 

Preferably, the module provides a CORBA-based client interface. 

In another embodiment, the module comprises a Web page interface. 

Preferably, the module comprises a VLR for interfacing with the HLR. 

In another embodiment, the module comprises means for handling transactions in an 
atomic manner. 

Preferably, the module comprises a Mobile Services Data Platform (MSDP) which 
provides multiple configuration capability. 
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In another embodiment, the module comprises at least two interfaces, one of which 
provides a backup. 



In a further embodiment, the module allows configuration of MAP messages which may 
5 be passed. 

Preferably, the module comprises means for maintaining a log of transactions resulting in 
changes to network data. 




10 Detailed Description of the Invention 



The invention will be more clearly understood from the following description of some 
embodiments thereof, given by way of example only with reference to the accompanying 
drawings in which:- 

15 

Fig. 1 is a diagram showing the context in which an interface module of the 
invention is connected, 

Fig. 2 is a high-level diagram showing signal transfers for interfacing, and 

Fig. 3 is a diagram of a platform architecture for the interface module. 

Referring to the drawings, and initially to Fig. 1 a customer 1 is shown accessing a client 
system 2, which in turn accesses an interface module ("EasyStar") 3. The interface 
25 module 3 is in a PLMN 4 within which it access a HLR 5. 

The module 3 provides a simple, CORBA-based interface over which client systems may 
manipulate subscriber feature data in any GSM HLR using MAP operations over the SS7 
network. The module is generic in so far as it may be configured to handle any feature 
30 whether standard or proprietary, available in a subscribers profile. The module 3 uses 



MAP operations, feature codes, and basic categories such as call forwarding and barring. 
The client system 2 provides the customer interfacing to present the features and then- 
data in a form understood by the subscribers. Therefore, the module 3 essentially 
provides a conduit through which client systems may issue MAP or INAP operations 
over the SS7 network. 

In one example, the module 3 supports a Web page interface over which, after suitable 
authorisation, subscribers may manipulate their own features over the Internet. The 
interface 3 comprises a simple Web page module which may be used to control standard 
features and allow users to build their own Web pages. The module 3 does not impose 
limitations on which features may be controlled and it is the responsibility of the client 
system to impose the necessary restrictions. 

The module 3 uses MAP or INAP operations to interface with the HLR. It is therefore 
able to inter-work with any HLR from any vendor. 

For compatibility, the operator's HLR should permit VLR to use the feature and 
password control MAP operations for a subscriber, even if that subscriber is not 
registered at the VLR. ' 

The module 1 comprises an API interface which allows client systems to view the 
module as a pipe to the HLR. There is a one-to-one relationship between the API 
operations and the associated MAP operations. All transactions are atomic, involving 
one invocation and a response. No transaction requires more than one invocation. This 
is illustrated in Fig. 2. 

A CORBA based interface is used over the Internet Inter-Orb Protocol (HOP). The 
methods provided by the interface are: 



Logon 



to establish an association. The standard CORBA authorisation 
services are used to identify the client. 



Logoff to explicitly end an association. If an association is inactive for a 

configurable period, EasyStar will automatically end it and the 
client will have to logon again (which, of course, it may do 
transparently to the user). 

Invoke to issue one or more MAP operations. All operations will be 

performed, whether or not the others are successful. Though the 
operations will normally be performed sequentially, EasyStar may 
change the order if that is expedient. The result of an invoke will 
comprise an attribute indicating the number of unsuccessful 
operations and the set of results received from the HLR. 

EasyStar restricts multiple operations in the same invoke to be for 
the same mobile number (MSISDN) 

Although the module 3 does not impose restrictions on the features, it does authenticate 
its clients. Individual clients may be configured to be restricted to certain operations and 
to the ranges of numbers they may manipulate. The client systems may establish one or 
more associations with the module 3 by providing a user identifier. 

The capabilities assigned to an EasyStar is client based on their permission include the 
following: 

• The ranges of directory numbers (MSISDN s) that the client is allowed to 
manipulate. A range can be a block or, in order to cater for number portability, 
single numbers. In fact the process is two tier. Clients are assigned the right to 



handle one or more groups of numbers (known as "markets"), which identify the 
permitted number ranges. 

• The MAP operations that the client is permitted to issue. For example a client can 
be restricted to just interrogating supplementary service data without being able to 
change them. 

Referring now to Fig. 3, the layered structure of the module 3 is illustrated. Fig. 3 
comprises an application 1 0 residing on a generic VLR module 1 1 , which in turn resides 
on a Mobile Services Data Platform (MSDP). In this embodiment, the operating system 
is a HP platform supporting HP OpenCall. The application 10 may co-exist on other 
applications on the MSDP. 

The MSDP supports very high availability configurations and mated pairs. The module 3 
may comprise two small systems, one providing a backup. The following features are 
provided. 

(a) All transactions are atomic and thus, providing a transaction was not being 
performed at the same time of the failure, an EasyStar client should be able to 
login into another EasyStar system and continue working without its users 
knowing. 

(b) If failure does occur during an update transaction, then the client system will need 
to perform appropriate recovery. The two simplest options are: 

Repeat the transaction 

Re-interrogate feature status and start again. 

(c) Apart from client authorisation and configuration data, no significant run-time 
data is maintained by EasyStar. This means that, provided a client is configured 
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on an EasyStar system, it can log-in and use it. However to facilitate operations 
and maintenance, EasyStar uses the MSDP distributed architecture capabilities to 
allow a single point of access for client oriented data, which are automatically 
distributed to the separate systems. 

5 

Regarding operations and support, the module 1 is fully configurable to allow 
customisation to meeting individual operators needs. 
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15 



20 



The main aspects of application configuration are: 

• The MAP messages that may be passed and any validation that must be 
performed on them before relaying. This is done with a simple scripting 
technique that uses the operation and attributes names in the MAP ASN.l 
specifications 

• Client system details, names, passwords and authorisation. This is performed 
using Java-based GUI screens. 

• All aspects of SS7 connectivity, sub-system numbers, addressing techniques, etc. 



The module 3 also keeps a log of all transactions resulting in changes to network data i.e. 
all transactions which changes a client profile. Interfaces are provided for inspecting the 
on-line and for down-loading them to other operations support systems for analysing 
and/or archiving. 
25 The following statistics of activity are maintained: - 



Number of each type of API operation received, 
Number of each MAP operation issued, 
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Number of errors of each type encountered. 

Counts are packaged up and written to a statistics log at configurable intervals such as 5 
to 1 5 minutes. 

The invention is not limited to the embodiments described but may be varied in 
construction and detail. 
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Claims 

1. An interface module comprising means for allowing client systems to read and 
write mobile subscriber feature data in a HLR. 

2. An interface module as claimed in claim 1, wherein the module uses MAP or 
INAP operations over a signalling network. 



3. An interface module as claimed in claims 1 or 2, wherein the module provides a 
10 CORBA-based client interface. 

4. An interface module as claimed in any preceding claim, wherein the module 
comprises a Web page interface. 

15 5. An interface module as claimed in any preceding claim, wherein the module 
comprises a VLR for interfacing with the HLR. 

6. An interface module as claimed in any preceding claim, wherein the module 
^ comprises means for handling transactions in an atomic manner. 

20 

7. An interface module as claimed in any preceding claim, wherein the module 
comprises a Mobile Services Data Platform (MSDP) which provides multiple 
configuration capability. 

25 8. An interface module as claimed in any preceding claim, wherein the module 
comprises at least two interfaces, one of which provides a backup. 



9. 



An interface module as claimed in claims 7 or 8, wherein the module allows 
configuration of MAP messages which may be passed. 



An interface module as claimed in any preceding claim, wherein the module 
comprises means for maintaining a log of transactions resulting in changes to 
network data. 



An interface module substantially as described with reference to the drawings. 



